Our modern connected world is facilitated by message processors communicating messages back and forth. A message processor may be quite complex such as a fully capable computing system or even a collection of computing systems. Message processors frequently use queues to exchange messages reliably while providing isolation between message processors. Queues allow message processors requesting a service (i.e., “clients”) to send application-level messages (hereinafter simply “messages”) at any time without requiring a direct connection to the message processor (i.e., the “service”) providing the service.
In a typical workflow process, a service instance is sometimes ready to handle messages, and sometimes not, depending on the service instance. If messages arrive out-of-order, the service instance may often not be able to handle the messages as they arrive.
Previous solutions to this problem fall into one of two categories: 1) those attempting to reimplement a secondary durable store to serve the workflow requests and 2) those attempting to handle out of order message consumption without regard to the underlying messaging transport. Neither category of solution fully embraced the ability to provide message assurances inside an existing durable store. The first category of solutions necessitated two or more locations for storing message data and complicated both verification of message assurances and transactional guarantees. The second category does not take advantage of queuing.